Conversation
Copilot
AI
changed the title
[WIP] Fix OpenApiSchemaReference non-spec-compliance in output
fix(library): enforce spec-compliant $ref serialization; add Extensions support for schema references in v3.1/v3.2
Mar 17, 2026
baywet
approved these changes
Mar 17, 2026
Co-authored-by: baywet <7905502+baywet@users.noreply.github.com>
…3.2; add SerializeAsV32 with loop detection - Add Extensions property to JsonSchemaReference (serialize in v3.1/v3.2 only) - Add Extensions setter to OpenApiSchemaReference (checks reference-level extensions first) - Add SerializeAsV32 override to OpenApiSchemaReference with loop detection - Read extension properties from $ref sibling keywords during v3.1 deserialization - Add tests for extensions in v3.1/v3.2 and verify extensions dropped in v3.0/v2 Co-authored-by: baywet <7905502+baywet@users.noreply.github.com>
Signed-off-by: Vincent Biret <vibiret@microsoft.com>
…ema references Signed-off-by: Vincent Biret <vibiret@microsoft.com>
Signed-off-by: Vincent Biret <vibiret@microsoft.com>
befb8f3 to
cba3dda
Compare
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Signed-off-by: Vincent Biret <vibiret@microsoft.com>
|
adrian05-ms
approved these changes
Mar 20, 2026
baywet
added a commit
that referenced
this pull request
Mar 20, 2026
…ference-description fix(library): enforce spec-compliant $ref serialization; add Extensions support for schema references in v3.1/v3.2
baywet
added a commit
that referenced
this pull request
Mar 20, 2026
Merge pull request #2782 from microsoft/copilot/fix-openapi-schema-reference-description
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.



Per OpenAPI spec, sibling keywords alongside
$refare version-dependent. For v2/v3.0 all siblings must be dropped; for v3.1/v3.2 schema refs, peer keywords including extensions are allowed; for v3.1/v3.2 non-schema refs, onlysummaryanddescriptionare permitted. This PR addresses the gap in extension support for schema references.Description
OpenApiSchemaReferencecorrectly drops sibling keywords (description, title, etc.) for v2/v3.0 serialization, but lacked support for serializing/deserializing extension properties (x-*) alongside$refin v3.1/v3.2, and was missing aSerializeAsV32override with loop detection.Type of Change
Related Issue(s)
Changes Made
JsonSchemaReferenceExtensionsproperty (IDictionary<string, IOpenApiExtension>?) — serialized only in v3.1/v3.2, silently dropped for v2/v3.0SerializeAdditionalV3XPropertiesnow callswriter.WriteExtensions(Extensions, OpenApiSpecVersion.OpenApi3_1)SetAdditional31MetadataFromMapNodenow parsesx-*properties from$refsibling keywords intoExtensionsOpenApiSchemaReferenceExtensionsupgraded from getter-only (Target?.Extensions) to get/set — reference-level extensions take priority over targetSerializeAsV32override with loop detection (matches existingSerializeAsV31pattern)PublicAPI.Unshipped.txtJsonSchemaReference.Extensions(get/set),OpenApiSchemaReference.Extensions.set,OpenApiSchemaReference.SerializeAsV32Tests
SerializeSchemaReferenceAsV31JsonWorksto include an extension; updated verified snapshotsSerializeSchemaReferenceAsV32JsonWorks+ snapshotsParseSchemaReferenceWithExtensionsWorks— parsesx-*from a v3.1$refnodeSchemaReferenceExtensionsNotWrittenInV30/SchemaReferenceExtensionsNotWrittenInV2— asserts only$refis emittedTesting
Checklist
Versions applicability
Additional Notes
Extension support is intentionally scoped to
JsonSchemaReference(schema refs only). Non-schema reference objects (OpenApiReferenceWithDescription,OpenApiReferenceWithDescriptionAndSummary) remain extension-free per the v3.1 Reference Object spec, which explicitly prohibits additional properties.Original prompt
This section details on the original issue you should resolve
<issue_title>OpenApiSchemaReference allows Description alongside $ref producing non-spec-compliant output in OAS 3.0 (clone of #2745)</issue_title>
<issue_description>## Description
The Microsoft.OpenApi library allows setting
DescriptiononOpenApiSchemaReference, which results in serialized output containing both$refanddescription.However, according to OpenAPI 3.0.x specification:
This makes
$refeffectively a replacement, meaning sibling keywords likedescriptionshould not appear.Example
Code
Output
Expected behavior
One of:
allOfDescription ignored when targeting OAS 3.0
Validation warning
Notes
In OAS 3.1 sibling keywords are allowed due to JSON Schema alignment
Behavior difference between 3.0 and 3.1 is currently unclear
This can lead to portability issues across tooling
This is a clone of OpenApiSchemaReference allows Description alongside $ref producing non-spec-compliant output in OAS 3.0 #2745
Question
What is the intended behavior when serializing references with annotations for OAS 3.0 vs 3.1?
</issue_description>
<agent_instructions>make sure you thoroughly consider my reply to implement the changes and tests</agent_instructions>
Comments on the Issue (you are @copilot in this section)
@baywet Hi @mdaneri,Thank you for using the SDK and for reaching out.
I think we need to break this down further:
OpenAPI 2 & 3.0
For any kind of reference (schema, path item, etc..), no sibling keyworks (description, summary, anything really) are allowed. We should drop them during serialization. Extension are not allowed either.
Source specification for v2
Source specification for v3
OpenAPI 3.1 & 3.2
For JSON Schema references, any keyword that's defined as a "peer keyword" can appear alongside the $ref property. That's effectively anything that has a setter in the reference type. Extensions are also allowed.
Source for schema object
For any other kind of reference (path item, etc...), ONLY summary and description are allowed alongside ...
💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.